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Abstract: 


Status: 


SAML profiles require agreements between system entities regarding identifiers, binding support 
and endpoints, certificates and keys, and so forth. A metadata specification is useful for 
describing this information in a standardized way. This document defines an extensible metadata 
format for SAML system entities, organized by roles that reflect SAML profiles. Such roles include 
that of Identity Provider, Service Provider, Affiliation, Attribute Authority, Attribute Consumer, and 
Policy Decision Point. 


This is an OASIS Standard document produced by the Security Services Technical Committee. It 
was approved by the OASIS membership on 1 March 2005. 


Committee members should submit comments and potential errata to the security- 
services@lists.oasis-open.org list. Others should submit them by filling out the web form located 
at http://www.oasis-open.org/committees/comments/form.php?wg abbrev=security. The 
committee will publish on its web page (http://www.oasis-open.org/committees/security) a catalog 
of any changes made to this document. 


For information on whether any patents have been disclosed that may be essential to 
implementing this specification, and any offers of patent licensing terms, please refer to the 
Intellectual Property Rights web page for the Security Services TC (http://www.oasis- 
open.org/committees/security/ipr.php). 
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1 Introduction 


SAML profiles require agreements between system entities regarding identifiers, binding support and 
endpoints, certificates and keys, and so forth. A metadata specification is useful for describing this 
information in a standardized way. This specification defines an extensible metadata format for SAML 
system entities, organized by roles that reflect SAML profiles. Such roles include that of SSO Identity 
Provider, SSO Service Provider, Affiliation, Attribute Authority, Attribute Requester, and Policy Decision 
Point. 


This specification further defines profiles for the dynamic exchange of metadata among system entities, 
which may be useful in some deployments. 


The SAML conformance document [SAMLConform] lists all of the specifications that comprise SAML 
V2.0. 


1.1 Notation 


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 
NOT", “RECOMMENDED”, “MAY”, and “OPTIONAL” in this specification are to be interpreted as 
described in IETF RFC 2119 [RFC2119]. 


Listings of productions or other normative code appear like this. 


Example code listings appear like this. 


Note: Notes like this are sometimes used to highlight non-normative commentary. 


Conventional XML namespace prefixes are used throughout this specification to stand for their respective 
namespaces as follows, whether or not a namespace declaration is present in the example: 


Prefix XML Namespace Comments 


saml: urn:oasis:names:tc:SAML:2.0:assertion This is the SAML V2.0 assertion namespace [SAML Core]. 
The prefix is generally elided in mentions of SAML 
assertion-related elements in text. 


samlp:  urn:oasis:names:tc:SAML 2.0:protocol This is the SAML V2.0 protocol namespace [SAML Core]. 
The prefix is generally elided in mentions of XML protocol- 
related elements in text. 


md: urn:oasis:names:tc:SAML:2.0:metadata This is the SAML V2.0 metadata namespace, defined ina 
schema [SAMLMeta-xsd]. 

ds: http://www.w3.org/2000/09/xmldsig# This is the XML Signature namespace [XMLSig]. 

xenc: http://www.w3.org/2001/04/xmlenc# This is the XML Encryption namespace [XMLEnc]. 

XS: http://www.w3.org/2001/XMLSchema This namespace is defined in the W3C XML Schema 


specification [Schema1]. In schema listings, this is the 
default namespace and no prefix is shown. For clarity, the 
prefix is generally shown in specification text when XML 
Schema-related constructs are mentioned. 
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12 2 Metadata for SAML V2.0 


153 SAML metadata is organized around an extensible collection of roles representing common combinations 
154 of SAML protocols and profiles supported by system entities. Each role is described by an element derived 
155 from the extensible base type of RoleDescriptor. Such descriptors are in turn collected into the 

156 «EntityDescriptor» container element, the primary unit of SAML metadata. An entity might 

157 alternatively represent an affiliation of other entities, such as an affiliation of service providers. The 

158 «AffiliationDescriptor» is provided for this purpose. 


159 Such descriptors may in turn be aggregated into nested groups using the <EntitiesDescriptor> 
160 element. 


161 A variety of security mechanisms for establishing the trustworthiness of metadata can be supported, 
162 particularly with the ability to individually sign most of the elements defined in this specification. 


163 Note that when elements with a parent/child relationship contain common attributes, such as caching or 
164 expiration information, the parent element takes precedence (see also Section 4.3.1). 


165 Note: As a general matter, SAML metadata is not to be taken as an authoritative 

166 statement about the capabilities or options of a given system entity. That is, while it should 
167 be accurate, it need not be exhaustive. The omission of a particular option does not imply 
168 that it is or is not unsupported, merely that it is not claimed. As an example, a SAML 

169 attribute authority might support any number of attributes not named in an 

170 <AttributeAuthorityDescriptor>. Omissions might reflect privacy or any number 

171 of other considerations. Conversely, indicating support for a given attribute does not imply 
172 that a given requester can or will receive it. 


173 2.1 Namespaces 


174 SAML Metadata uses the following namespace (defined in a schema [SAMLMeta-xsq]): 
175 urn:oasis:names:tc:SAML:2.0:metadata 


176 This specification uses the namespace prefix md: to refer to the namespace above. 


177 The following schema fragment illustrates the use of namespaces in SAML metadata documents: 


178 «schema 
179 targetNamespace="urn:oasis:names:tc:SAML:2.0:metadata" 
180 xmlns:md-"urn:oasis:names:tc:SAML:2.0:metadata" 
181 xmlns:ds="http://www.w3.0rg/2000/09/xmldsigt" 
182 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
183 xmlns:saml-"urn:oasis:names:tc:SAML:2.0:assertion" 
184 xmlns="http://www.w3.0rg/2001/XMLSchema" 
185 elementFormDefault="unqualified" 
186 attributeFormDefault="unqualified" 
187 blockDefault="substitution" 
188 version="2.0"> 
189 «import namespace="http://www.w3.org/2000/09/xmldsig#" 
190 SchemaLocation-"http://www.w3.org/TR/2002/REC-xmldsig-core- 
191 20020212/xmldsig-core-schema.xsd"/» 
192 «import namespace="http://www.w3.org/2001/04/xmlenc#" 
193 SchemaLocation-"http://www.w3.org/TR/2002/REC-xmlenc-core- 
194 20021210/xenc-schema.xsd"/» 
195 «import namespace-"urn:oasis:names:tc:SAML:2.0:assertion" 
196 schemaLocation="saml-schema-assertion-2.0.xsd"/> 
197 <import namespace="http://www.w3.org/XML/1998/namespace" 
198 schemaLocation="http://www.w3.org/2001/xml.xsd"/> 
199 <annotation> 
200 <documentation> 
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Document identifier: saml-schema-metadata-2.0 
Location: http://docs.oasis-open.org/security/saml/v2.0/ 
Revision history: 
W2.0 (eee, 2005) ¢ 
Schema for SAML metadata, first published in SAML 2.0. 
</documentation> 
</annotation> 


</schema> 


2.2 Common Types 


The SAML V2.0 Metadata specification defines several types as described in the following subsections. 
These types are used in defining SAML V2.0 Metadata elements and attributes. 


2.2.1 Simple Type entityIDType 


The simple type entityIDType restricts the XML schema data type anyURI to a maximum length of 1024 
characters. entitylDType is used as a unique identifier for SAML entities. See also Section 8.3.6 of 
[SAMLCore]. An identifier of this type MUST be unique across all entities that interact within a given 
deployment. The use of a URI and holding to the rule that a single URI MUST NOT refer to different 
entities satisfies this requirement. 


The following schema fragment defines the entityIDType simple type: 


<simpleType name="entityIDType"> 
<restriction base="anyURI"> 
<maxLength value="1024"/> 
</restriction> 
</simpleType> 


2.2.2 Complex Type EndpointType 


The complex type EndpointType describes a SAML protocol binding endpoint at which a SAML entity can 
be sent protocol messages. Various protocol or profile-specific metadata elements are bound to this type. 
It consists of the following attributes: 


Binding [Required] 


A required attribute that specifies the SAML binding supported by the endpoint. Each binding is 
assigned a URI to identify it. 


Location [Required] 


A required URI attribute that specifies the location of the endpoint. The allowable syntax of this 
URI depends on the protocol binding. 


ResponseLocation [Optional] 


Optionally specifies a different location to which response messages sent as part of the protocol 
or profile should be sent. The allowable syntax of this URI depends on the protocol binding. 


The ResponseLocation attribute is used to enable different endpoints to be specified for receiving 
request and response messages associated with a protocol or profile, not as a means of load-balancing or 
redundancy (multiple elements of this type can be included for this purpose). When a role contains an 
element of this type pertaining to a protocol or profile for which only a single type of message (request or 
response) is applicable, then the ResponseLocation attribute is unused. 


In most contexts, elements of this type appear in unbounded sequences in the schema. This is to permit a 
protocol or profile to be offered by an entity at multiple endpoints, usually with different protocol bindings, 
allowing the metadata consumer to choose an appropriate endpoint for its needs. Multiple endpoints might 
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also offer "client-side" load-balancing or failover, particular in the case of a synchronous protocol binding. 


This element also permits the use of arbitrary elements and attributes defined in a non-SAML namespace. 
Any such content MUST be namespace-qualified. 


The following schema fragment defines the EndpointType complex type: 


<complexType name="EndpointType"> 


<sequence> 
«any namespace="##other" processContents-"lax" minOccurs="0" 
maxOccurs="unbounded"/> 
</sequence> 


<attribute name="Binding" type="anyURI" use="required"/> 

«attribute name="Location" type-"anyURI" use="required"/> 

<attribute name-"ResponseLocation" type="anyURI" use="optional"/> 

<anyAttribute namespace="##other" processContents-"lax"/» 
</complexType> 


2.2.3 Complex Type IndexedEndpointType 


The complex type IndexedEndpointType extends EndpointType with a pair of attributes to permit the 
indexing of otherwise identical endpoints so that they can be referenced by protocol messages. It consists 
of the following additional attributes: 


index [Required] 
A required attribute that assigns a unique integer value to the endpoint so that it can be 
referenced in a protocol message. The index value need only be unique within a collection of like 


elements contained within the same parent element (i.e., they need not be unique across the 
entire instance). 


isDefault [Optional] 
An optional boolean attribute used to designate the default endpoint among an indexed set. If 
omitted, the value is assumed to be false. 


In any such sequence of like endpoints based on this type, the default endpoint is the first such endpoint 
with the isDefault attribute set to true. If no such endpoints exist, the default endpoint is the first such 
endpoint without the isDefault attribute set to false. If no such endpoints exist, the default endpoint is 
the first element in the sequence. 


The following schema fragment defines the IndexedEndpointType complex type: 


<complexType name="IndexedEndpointType"> 
<complexContent> 
<extension base="md:EndpointType"> 
<attribute name="index" type="unsignedShort" use="required"/> 
<attribute name="isDefault" type="boolean" use="optional"/> 
</extension> 
</complexContent> 
</complexType> 


2.2.4 Complex Type localizedNameType 


The localizedNameType complex type extends a string-valued element with a standard XML language 
attribute. The following schema fragment defines the localizedNameType complex type: 


<complexType name="localizedNameType"> 
<simpleContent> 
<extension base="string"> 
<attribute ref="xml:lang" use="required"/> 
</extension> 
</simpleContent> 
</complexType> 
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2.2.5 Complex Type localizedURIType 


The localizedURIType complex type extends a URI-valued element with a standard XML language 
attribute. 


The following schema fragment defines the localizedURIType complex type: 


<complexType name="localizedURIType"> 
<simpleContent> 
<extension base="anyURI"> 
<attribute ref="xml:lang" use="required"/> 
</extension> 
</simpleContent> 
</complexType> 


2.3 Root Elements 


A SAML metadata instance describes either a single entity or multiple entities. In the former case, the root 
element MUST be <EntityDescriptor>. In the latter case, the root element MUST be 
<EntitiesDescriptor>. 


2.3.1 Element <EntitiesDescriptor> 


The <EntitiesDescriptor> element contains the metadata for an optionally named group of SAML 
entities. Its EntitiesDescriptorType complex type contains a sequence of <EntityDescriptor> 
elements, «EntitiesDescriptor» elements, or both: 


ID [Optional] 
A document-unique identifier for the element, typically used as a reference point when signing. 


validUntil [Optional] 
Optional attribute indicates the expiration time of the metadata contained in the element and any 
contained elements. 

cacheDuration [Optional] 
Optional attribute indicates the maximum length of time a consumer should cache the metadata 
contained in the element and any contained elements. 

Name [Optional] 
A string name that identifies a group of SAML entities in the context of some deployment. 


«ds:Signature» [Optional] 


An XML signature that authenticates the containing element and its contents, as described in 
Section 3. 


«Extensions» [Optional] 


This contains optional metadata extensions that are agreed upon between a metadata publisher 
and consumer. Extension elements MUST be namespace-qualified by a non-SAML defined 
namespace. 


<EntitiesDescriptor> or«EntityDescriptor» [One or More] 
Contains the metadata for one or more SAML entities, or a nested group of additional metadata. 
When used as the root element of a metadata instance, this element MUST contain either a validUntil 


or cacheDurat ion attribute. It is RECOMMENDED that only the root element of a metadata instance 
contain either attribute. 
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The following schema fragment defines the «EntitiesDescriptor» element and its 
EntitiesDescriptorType complex type: 


<element name-"EntitiesDescriptor" type-"md:EntitiesDescriptorType"/» 
<complexType name="EntitiesDescriptorType"> 
<sequence> 
<element ref="ds:Signature" minOccurs="0"/> 
<element ref-"md:Extensions" minOccurs="0"/> 
<choice minOccurs="1" maxOccurs="unbounded"> 
<element ref="md:EntityDescriptor"/> 
<element ref="md:EntitiesDescriptor"/> 
</choice> 
</sequence> 
<attribute name="validUntil" type="dateTime" use="optional"/> 
<attribute name-"cacheDuration" type-"duration" use-"optional"/» 
«attribute name-"ID" type-"ID" use-"optional"/» 
«attribute name-"Name" type-"string" use-"optional"/» 
</complexType> 
<element name="Extensions" type="md:ExtensionsType"/> 
<complexType final="#all" name="ExtensionsType"> 
<sequence> 
<any namespace="##other" processContents="lax" maxOccurs="unbounded"/> 
</sequence> 
</complexType> 


2.3.2 Element <EntityDescriptor> 


The <EntityDescriptor> element specifies metadata for a single SAML entity. A single entity may act 
in many different roles in the support of multiple profiles. This specification directly supports the following 
concrete roles as well as the abstract <RoleDescriptor> element for extensibility (see subsequent 
sections for more details): 


* SSO Identity Provider 

* SSO Service Provider 

* Authentication Authority 
* Attribute Authority 

* Policy Decision Point 

* Affiliation 


Its EntityDescriptorType complex type consists of the following elements and attributes: 


entityID [Required] 
Specifies the unique identifier of the SAML entity whose metadata is described by the element's 
contents. 

ID [Optional] 
A document-unique identifier for the element, typically used as a reference point when signing. 


validUntil [Optional] 
Optional attribute indicates the expiration time of the metadata contained in the element and any 
contained elements. 

cacheDuration [Optional] 


Optional attribute indicates the maximum length of time a consumer should cache the metadata 
contained in the element and any contained elements. 
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«ds:Signature» [Optional] 


An XML signature that authenticates the containing element and its contents, as described in 
Section 3. 


«Extensions» [Optional] 


This contains optional metadata extensions that are agreed upon between a metadata publisher 
and consumer. Extension elements MUST be namespace-qualified by a non-SAML-defined 
namespace. 


<RoleDescriptor>, <IDPSSODescriptor>, <SPSSODescriptor>, 
<AuthnAuthorityDescriptor>, <AttributeAuthorityDescriptor>, <PDPDescriptor> [One 
or More] 


OR 

<AffiliationDescriptor> [Required] 
The primary content of the element is either a sequence of one or more role descriptor elements, 
or a specialized descriptor that defines an affiliation. 

<Organization> [Optional] 
Optional element identifying the organization responsible for the SAML entity described by the 
element. 

<ContactPerson> [Zero or More] 
Optional sequence of elements identifying various kinds of contact personnel. 


<AdditionalMetadataLocation> [Zero or More] 


Optional sequence of namespace-qualified locations where additional metadata exists for the 
SAML entity. This may include metadata in alternate formats or describing adherence to other 
non-SAML specifications. 


Arbitrary namespace-qualified attributes from non-SAML-defined namespaces may also be included. 


When used as the root element of a metadata instance, this element MUST contain either a validUntil 
or cacheDuration attribute. It is RECOMMENDED that only the root element of a metadata instance 
contain either attribute. 


It is RECOMMENDED that if multiple role descriptor elements of the same type appear, that they do not 
share overlapping protocolSupportEnumeration values. Selecting from among multiple role 
descriptor elements of the same type that do share a protocolSupportEnumeration value is 
undefined within this specification, but MAY be defined by metadata profiles, possibly through the use of 
other distinguishing extension attributes. 


The following schema fragment defines the <EntityDescriptor> element and its 
EntityDescriptorType complex type: 


<element name-"EntityDescriptor" type="md:EntityDescriptorType"/> 
<complexType name="EntityDescriptorType"> 
<sequence> 
<element ref="ds:Signature" minOccurs="0"/> 
<element ref-"md:Extensions" minOccurs="0"/> 
<choice> 
<choice maxOccurs="unbounded"> 
<element ref="md:RoleDescriptor"/> 
<element ref-"md:IDPSSODescriptor"/» 
<element ref="md:SPSSODescriptor"/> 
<element ref="md:AuthnAuthorityDescriptor"/> 
<element ref="md:AttributeAuthorityDescriptor"/> 
<element ref="md:PDPDescriptor"/> 
</choice> 
<element ref="md:AffiliationDescriptor"/> 


saml-metadata-2.0-os 15 March 2005 
Copyright € OASIS Open 2005 All Rights Reserved. Page 11 of 43 


431 
432 
433 
434 
435 
436 
437 
438 
439 
440 
441 
442 


443 


444 
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454 
455 


456 


457 
458 
459 


460 


461 
462 


463 
464 
465 
466 
467 
468 
469 
470 
471 
472 
473 
474 
475 


476 


477 
478 
479 


</choice> 
<element ref-"md:Organization" minOccurs="0"/> 
<element ref="md:ContactPerson" minOccurs="0" maxOccurs="unbounded"/> 
<element ref-"md:AdditionalMetadataLocation" minOccurs="0" 
maxOccurs-"unbounded"/» 
</sequence> 
<attribute name-"entityID" type-"md:entityIDType" use="required"/> 
<attribute name="validUntil" type="dateTime" use="optional"/> 
<attribute name="cacheDuration" type="duration" use="optional"/> 
<attribute name="ID" type="ID" use="optional"/> 
<anyAttribute namespace="##other" processContents-"lax"/» 
</complexType> 


2.3.2.1 Element <Organization> 


The <Organization> element specifies basic information about an organization responsible for a SAML 
entity or role. The use of this element is always optional. Its content is informative in nature and does not 
directly map to any core SAML elements or attributes. Its OrganizationType complex type consists of the 
following elements: 


<Extensions> [Optional] 
This contains optional metadata extensions that are agreed upon between a metadata publisher 
and consumer. Extensions MUST NOT include global (non-namespace-qualified) elements or 
elements qualified by a SAML-defined namespace within this element. 

<OrganizationName> [One or More] 

One or more language-qualified names that may or may not be suitable for human consumption. 


<OrganizationDisplayName> [One or More] 
One or more language-qualified names that are suitable for human consumption. 


<OrganizationURL> [One or More] 


One or more language-qualified URIs that specify a location to which to direct a user for additional 
information. Note that the language qualifier refers to the content of the material at the specified 
location. 


Arbitrary namespace-qualified attributes from non-SAML-defined namespaces may also be included. 


The following schema fragment defines the <Organization> element and its OrganizationType 
complex type: 


<element name-"Organization" type-"md:OrganizationType"/» 
<complexType name="OrganizationType"> 
<sequence> 
<element ref-"md:Extensions" minOccurs="0"/> 
<element ref="md:OrganizationName" maxOccurs="unbounded"/> 
<element ref="md:OrganizationDisplayName" maxOccurs="unbounded"/> 
<element ref="md:OrganizationURL" maxOccurs="unbounded"/> 
</sequence> 
«anyAttribute namespace="##other" processContents-"lax"/» 
</complexType> 
<element name-"OrganizationName" type="md: localizedNameType"/> 
<element name-"OrganizationDisplayName" type="md:localizedNameType"/> 
<element name-"OrganizationURL" type="md:localizedURIType"/> 


2.3.2.2 Element <ContactPerson> 


The <ContactPerson> element specifies basic contact information about a person responsible in some 
capacity for a SAML entity or role. The use of this element is always optional. Its content is informative in 
nature and does not directly map to any core SAML elements or attributes. Its ContactType complex type 
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480 consists of the following elements and attributes: 


481  contactType [Required] 


482 Specifies the type of contact using the ContactTypeType enumeration. The possible values are 
483 technical, support, administrative, billing, and other 


484 «Extensions» [Optional] 


485 This contains optional metadata extensions that are agreed upon between a metadata publisher 
486 and consumer. Extension elements MUST be namespace-qualified by a non-SAML defined 
487 namespace. 


488 «Company» [Optional] 
489 Optional string element that specifies the name of the company for the contact person. 


490  «GivenName» [Optional] 
491 Optional string element that specifies the given (first) name of the contact person. 


492 <SurName> [Optional] 


493 Optional string element that specifies the surname of the contact person. 

494  «EmailAddress» [Zero or More] 

495 Zero or more elements containing mailto: URIs representing e-mail addresses belonging to the 
496 contact person. 


497 <TelephoneNumber> [Zero or More] 


498 Zero or more string elements specifying a telephone number of the contact person. 


499 Arbitrary namespace-qualified attributes from non-SAML-defined namespaces may also be included. 


500 The following schema fragment defines the <ContactPerson> element and its ContactType complex 
501 type: 


502 <element name-"ContactPerson" type-"md:ContactType"/» 
503 <complexType name="ContactType"> 
504 <sequence> 
505 <element ref-"md:Extensions" minOccurs="0"/> 
506 «element ref="md:Company" minOccurs="0"/> 
507 <element ref="md:GivenName" minOccurs="0"/> 
508 <element ref="md:SurName" minOccurs="0"/> 
509 <element ref="md:EmailAddress" minOccurs="0" maxOccurs="unbounded"/> 
510 «element ref="md:TelephoneNumber" minOccurs="0" maxOccurs="unbounded"/> 
511 </sequence> 
512 <attribute name="contactType" type-"md:ContactTypeType" use="required"/> 
513 «anyAttribute namespace="##other" processContents-"lax"/» 
514 «/complexType» 
515 <element name-"Company" type="string"/> 
516 <element name="GivenName" type="string"/> 
517 <element name="SurName" type="string"/> 
518 <element name="EmailAddress" type="anyURI"/> 
519 <element name="TelephoneNumber" type="string"/> 
520 <simpleType name="ContactTypeType"> 
521 <restriction base="string"> 
522 <enumeration value="technical"/> 
523 <enumeration value="support"/> 
524 <enumeration value="administrative"/> 
525 <enumeration value="billing"/> 
526 <enumeration value="other"/> 
527 </restriction> 
528 </simpleType> 
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2.3.2.3 Element <AdditionalMetadataLocation> 


The <AdditionalMetadataLocation> element is a namespace-qualified URI that specifies where 
additional XML-based metadata may exist for a SAML entity. Its AdditionalMetadataLocationType 
complex type extends the anyURI type with a namespace attribute (also of type anyURI). This required 
attribute MUST contain the XML namespace of the root element of the instance document found at the 
specified location. 


The following schema fragment defines the <AdditionalMetadataLocation> element and its 
AdditionalMetadataLocationType complex type: 


Xelement name-"AdditionalMetadataLocation" 
type-"md:AdditionalMetadataLocationType"/» 
<complexType name="AdditionalMetadataLocationType"> 
<simpleContent> 
<extension base="anyURI"> 
<attribute name="namespace" type="anyURI" use="required"/> 
</extension> 
</simpleContent> 
</complexType> 


2.4 Role Descriptor Elements 


The elements in this section make up the bulk of the operational support component of the metadata. 
Each element (save for the abstract one) defines a specific collection of operational behaviors in support 
of SAML profiles defined in [SAMLProf]. 


2.4.1 Element <RoleDescriptor> 


The <RoleDescriptor> element is an abstract extension point that contains common descriptive 
information intended to provide processing commonality across different roles. New roles can be defined 
by extending its abstract RoleDescriptorType complex type, which contains the following elements and 
attributes: 
ID [Optional] 

A document-unique identifier for the element, typically used as a reference point when signing. 


validUntil [Optional] 
Optional attribute indicates the expiration time of the metadata contained in the element and any 
contained elements. 

cacheDuration [Optional] 


Optional attribute indicates the maximum length of time a consumer should cache the metadata 
contained in the element and any contained elements. 


protocolSupportEnumeration [Required] 


A whitespace-delimited set of URIs that identify the set of protocol specifications supported by the 
role element. For SAML V2.0 entities, this set MUST include the SAML protocol namespace URI, 
urn:oasis:names:tc:SAML:2.0:protocol. Note that future SAML specifications might 
share the same namespace URI, but SHOULD provide alternate "protocol support" identifiers to 
ensure discrimination when necessary. 


errorURL [Optional] 


Optional URI attribute that specifies a location to direct a user for problem resolution and 
additional support related to this role. 
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618 
619 


«ds:Signature» [Optional] 


An XML signature that authenticates the containing element and its contents, as described in 
Section 3. 


«Extensions» [Optional] 
This contains optional metadata extensions that are agreed upon between a metadata publisher 
and consumer. Extension elements MUST be namespace-qualified by a non-SAML-defined 
namespace. 

«KeyDescriptor» [Zero or More] 
Optional sequence of elements that provides information about the cryptographic keys that the 
entity uses when acting in this role. 

«Organization» [Optional] 


Optional element specifies the organization associated with this role. Identical to the element used 
within the <EntityDescriptor> element. 


«ContactPerson» [Zero or More] 


Optional sequence of elements specifying contacts associated with this role. Identical to the 
element used within the «Ent ityDescriptor» element. 


Arbitrary namespace-qualified attributes from non-SAML-defined namespaces may also be included. 


The following schema fragment defines the <RoleDescriptor> element and its RoleDescriptorType 
complex type: 


<element name-"RoleDescriptor" type="md:RoleDescriptorType"/> 
<complexType name-"RoleDescriptorType" abstract-"true"» 
«sequence» 
<element ref-"ds:Signature" minOccurs="0"/> 
<element ref="md:Extensions" minOccurs="0"/> 
<element ref-"md:KeyDescriptor" minOccurs="0" maxOccurs-"unbounded"/» 
<element ref-"md:Organization" minOccurs="0"/> 
<element ref="md:ContactPerson" minOccurs="0" maxOccurs="unbounded"/> 
</sequence> 
<attribute name="ID" type="ID" use="optional"/> 
<attribute name="validUntil" type="dateTime" use="optional"/> 
<attribute name-"cacheDuration" type-"duration" use-"optional"/» 
«attribute name-"protocolSupportEnumeration" type-"md:anyURIListType" 
use-"required"/» 
«attribute name-"errorURL" type-"anyURI" use-"optional"/» 
«anyAttribute namespace="##other" processContents-"lax"/» 
</complexType> 
<simpleType name="anyURIListType"> 
<list itemType="anyURI"/> 
</simpleType> 


2.4.1.1 Element <KeyDescriptor> 


The <KeyDescriptor> element provides information about the cryptographic key(s) that an entity uses 
to sign data or receive encrypted keys, along with additional cryptographic details. Its KeyDescriptorType 
complex type consists of the following elements and attributes: 

use [Optional] 


Optional attribute specifying the purpose of the key being described. Values are drawn from the 
KeyTypes enumeration, and consist of the values encryption and signing. 


«ds:KeyInfo» [Required] 
Optional element that directly or indirectly identifies a key. See [XMLSig] for additional details on 
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620 the use of this element. 


621 <EncryptionMethod> [Zero or More] 


622 Optional element specifying an algorithm and algorithm-specific settings supported by the entity. 
623 The exact content varies based on the algorithm supported. See [XMLEnc] for the definition of this 
624 element's xenc:EncryptionMethodType complex type. 


625 The following schema fragment defines the <KeyDescriptor> element and its KeyDescriptorType 
626 complex type: 


627 <element name-"KeyDescriptor" type-"md:KeyDescriptorType"/» 
628 <complexType name="KeyDescriptorType"> 

629 <sequence> 

630 <element ref-"ds:KeyInfo"/» 

631 <element ref="md:EncryptionMethod" minOccurs="0" 

632 maxOccurs="unbounded"/> 

633 «/sequence» 

634 «attribute name-"use" type-"md:KeyTypes" use-"optional"/» 
635 «/complexType» 

636 <simpleType name="KeyTypes"> 

637 <restriction base="string"> 

638 <enumeration value="encryption"/> 

639 <enumeration value="signing"/> 

640 L/restrietisa> 

641 </simpleType> 

642 <element name="EncryptionMethod" type="xenc:EncryptionMethodType"/> 


643 2.4.2 Complex Type SSODescriptorType 


644 The SSODescriptorType abstract type is a common base type for the concrete types 

645  SPSSODescriptorType and IDPSSODescriptorType, described in subsequent sections. It extends 
646  RoleDescriptorType with elements reflecting profiles common to both identity providers and service 
647 providers that support SSO, and contains the following additional elements: 


648  «ArtifactResolutionService» [Zero or More] 


649 Zero or more elements of type IndexedEndpointType that describe indexed endpoints that 
650 support the Artifact Resolution profile defined in [SAMLProf]. The ResponseLocation attribute 
651 MUST be omitted. 


652 <SingleLogoutService> [Zero or More] 


653 Zero or more elements of type EndpointType that describe endpoints that support the Single 
654 Logout profiles defined in [SAMLProf]. 

655 <ManageNameIDService> [Zero or More] 

656 Zero or more elements of type EndpointType that describe endpoints that support the Name 
657 Identifier Management profiles defined in [SAMLProf]. 

658 <NameIDFormat> [Zero or More] 

659 Zero or more elements of type anyURI that enumerate the name identifier formats supported by 
660 this system entity acting in this role. See Section 8.3 of [SAMLCore] for some possible values for 
661 this element. 


662 The following schema fragment defines the SSODescriptorType complex type: 


663 <complexType name-"SSODescriptorType" abstract="true"> 
664 <complexContent> 
665 <extension base="md:RoleDescriptorType"> 
666 <sequence> 
667 <element ref-"md:ArtifactResolutionService" minOccurs="0" 
668 maxOccurs="unbounded"/> 
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<element ref-"md:SingleLogoutService" minOccurs="0" 
maxOccurs="unbounded"/> 
<element ref-"md:ManageNameIDService" minOccurs="0" 
maxOccurs="unbounded"/> 
<element ref-"md:NamelDFormat" minOccurs="0" 
maxOccurs="unbounded"/> 
</sequence> 
</extension> 
</complexContent> 
</complexType> 
<element name="ArtifactResolutionService" type="md: IndexedEndpointType"/> 
<element name="SingleLogoutService" type="md:EndpointType"/> 
<element name-"ManageNameIDService" type="md:EndpointType"/> 
<element name-"NameIDFormat" type="anyURI"/> 


2.4.3 Element <IDPSSODescriptor> 


The <IDPSSODescriptor> element extends SSODescriptorType with content reflecting profiles 
specific to identity providers supporting SSO. Its IDPSSODescriptorType complex type contains the 
following additional elements and attributes: 


WantAuthnRequestsSigned [Optional] 
Optional attribute that indicates a requirement for the <samlp:AuthnRequest> messages 
received by this identity provider to be signed. If omitted, the value is assumed to be false. 
<SingleSignOnService> [One or More] 


One or more elements of type EndpointType that describe endpoints that support the profiles of 
the Authentication Request protocol defined in [SAMLProf]. All identity providers support at least 
one such endpoint, by definition. The ResponseLocation attribute MUST be omitted. 


<NameIDMappingService> [Zero or More] 


Zero or more elements of type EndpointType that describe endpoints that support the Name 
Identifier Mapping profile defined in [SAMLProf]. The ResponseLocation attribute MUST be 
omitted. 


«AssertionIDRequestService» [Zero or More] 


Zero or more elements of type EndpointType that describe endpoints that support the profile of 
the Assertion Request protocol defined in [SAML Prof] or the special URI binding for assertion 
requests defined in [SAMLBind]. 


«AttributeProfile» [Zero or More] 
Zero or more elements of type anyURI that enumerate the attribute profiles supported by this 
identity provider. See [SAML Prof] for some possible values for this element. 
«saml:Attribute» [Zero or More] 


Zero or more elements that identify the SAML attributes supported by the identity provider. 
Specific values MAY optionally be included, indicating that only certain values permitted by the 
attribute's definition are supported. In this context, "support" for an attribute means that the identity 
provider has the capability to include it when delivering assertions during single sign-on. 


The following schema fragment defines the <IDPSSODescriptor> element and its 
IDPSSODescriptorType complex type: 


«element name-"IDPSSODescriptor" type="md:IDPSSODescriptorType"/> 
<complexType name="IDPSSODescriptorType"> 
<complexContent> 
<extension base="md:SSODescriptorType"> 
<sequence> 
<element ref-"md:SingleSignOnService" maxOccurs="unbounded"/> 
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<element ref-"md:NamelDMappingService" minOccurs="0" 
maxOccurs="unbounded"/> 
<element ref="md:AssertionIDRequestService" minOccurs="0" 
maxOccurs="unbounded"/> 
<element ref="md:AttributeProfile" minOccurs="0" 
maxOccurs="unbounded"/> 
<element ref="saml:Attribute" minOccurs="0" 
maxOccurs="unbounded"/> 
</sequence> 
<attribute name="WantAuthnRequestsSigned" type="boolean" 
use="optional"/> 
</extension> 
</complexContent> 
</complexType> 
<element name-"SingleSignOnService" type="md:EndpointType"/> 
<element name-"NameIDMappingService" type="md:EndpointType"/> 
<element name-"AssertionIDRequestService" type="md:EndpointType"/> 
<element name="AttributeProfile" type="anyURI"/> 


2.4.4 Element <SPSSODescriptor> 


The <SPSSODescriptor> element extends SSODescriptorType with content reflecting profiles specific 
to service providers. Its SPSSODescriptorType complex type contains the following additional elements 
and attributes: 


AuthnRequestsSigned [Optional] 


Optional attribute that indicates whether the «sam1p:AuthnRequest» messages sent by this 
service provider will be signed. If omitted, the value is assumed to be false. 


WantAssertionsSigned [Optional] 


Optional attribute that indicates a requirement for the «sam1:Assertion» elements received by 
this service provider to be signed. If omitted, the value is assumed to be false. This requirement 
is in addition to any requirement for signing derived from the use of a particular profile/binding 
combination. 


«AssertionConsumerService» [One or More] 


One or more elements that describe indexed endpoints that support the profiles of the 
Authentication Request protocol defined in [SAMLProf]. All service providers support at least one 
such endpoint, by definition. 


«AttributeConsumingService» [Zero or More] 
Zero or more elements that describe an application or service provided by the service provider 
that requires or desires the use of SAML attributes. 


At most one «AttributeConsumingService» element can have the attribute isDefault set to 
true. It is permissible for none of the included elements to contain an isDefault attribute set to true. 


The following schema fragment defines the <SPSSODescriptor> element and its 
SPSSODescriptorType complex type: 


<element name-"SPSSODescriptor" type-"md:SPSSODescriptorType"/» 
<complexType name="SPSSODescriptorType"> 
<complexContent> 
<extension base="md:SSODescriptorType"> 
<sequence> 
<element ref="md:AssertionConsumerService" 
maxOccurs="unbounded"/> 
<element ref="md:AttributeConsumingService" minOccurs="0" 
maxOccurs="unbounded"/> 
</sequence> 
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<attribute name="AuthnRequestsSigned" type="boolean" 
use="optional"/> 

<attribute name="WantAssertionsSigned" type="boolean" 
use="optional"/> 

</extension> 
</complexContent> 

</complexType> 
<element name-"AssertionConsumerService" type="md: IndexedEndpointType"/> 


2.4.4.1 Element <AttributeConsumingService> 


The <AttributeConsumingService> element defines a particular service offered by the service 
provider in terms of the attributes the service requires or desires. Its AttributeConsumingServiceType 
complex type contains the following elements and attributes: 


index [Required] 
A required attribute that assigns a unique integer value to the element so that it can be referenced 
in a protocol message. 
isDefault [Optional] 
Identifies the default service supported by the service provider. Useful if the specific service is not 
otherwise indicated by application context. If omitted, the value is assumed to be false. 
<ServiceName> [One or More] 
One or more language-qualified names for the service. 


<ServiceDescription> [Zero or More] 
Zero or more language-qualified strings that describe the service. 


<RequestedAttribute> [One or More] 
One or more elements specifying attributes required or desired by this service. 


The following schema fragment defines the <AttributeRequestingService> element and its 
AttributeRequestingServiceType complex type: 


<element name="AttributeConsumingService" 
type="md:AttributeConsumingServiceType"/> 
<complexType name="AttributeConsumingServiceType"> 
<sequence> 
<element ref="md:ServiceName" maxOccurs="unbounded"/> 
<element ref="md:ServiceDescription" minOccurs="0" 
maxOccurs="unbounded"/> 
«element ref="md:RequestedAttribute" maxOccurs-"unbounded"/» 
</sequence> 
<attribute name="index" type="unsignedShort" use="required"/> 
«attribute name-"isDefault" type-"boolean" use="optional"/> 
</complexType> 
<element name="ServiceName" type-"md:localizedNameType"/» 
«element name="ServiceDescription" type="md:localizedNameType"/> 


2.4.4.2 Element <RequestedAttribute> 


The <RequestedAttribute> element specifies a service provider's interest in a specific SAML 
attribute, optionally including specific values. Its RequestedAttributeType complex type extends the 
saml:AttributeType with the following attribute: 


isRequired [Optional] 


Optional XML attribute indicates if the service requires the corresponding SAML attribute in order 
to function at all (as opposed to merely finding an attribute useful or desirable). 
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816 If specific <saml:AttributeValue> elements are included, then only matching values are relevant to 
817 the service. See [SAMLCore] for more information on attribute value matching. 


818 The following schema fragment defines the <RequestedAttribute> element and its 
819  RequestedAttributeType complex type: 


820 <element name-"RequestedAttribute" type-"md:RequestedAttributeType"/» 
821 <complexType name="RequestedAttributeType"> 

822 <complexContent> 

823 <extension base="saml:AttributeType"> 

824 <attribute name="isRequired" type="boolean" use="optional"/> 
825 </extension> 

826 </complexContent> 

827 </complexType> 


s8 2.4.5 Element <AuthnAuthorityDescriptor> 


829 The <AuthnAuthorityDescriptor> element extends RoleDescriptorType with content reflecting 
830 profiles specific to authentication authorities, SAML authorities that respond to <samlp: AuthnQuery> 
831 messages. Its AuthnAuthorityDescriptorType complex type contains the following additional element: 


832  «AuthnQueryService» [One or More] 


833 One or more elements of type EndpointType that describe endpoints that support the profile of 
834 the Authentication Query protocol defined in [SAMLProf]. All authentication authorities support at 
835 least one such endpoint, by definition. 


836 <AssertionIDRequestService> [Zero or More] 


837 Zero or more elements of type EndpointType that describe endpoints that support the profile of 
838 the Assertion Request protocol defined in [SAML Prof] or the special URI binding for assertion 
839 requests defined in [SAMLBind]. 

840 <NameIDFormat> [Zero or More] 

841 Zero or more elements of type anyURI that enumerate the name identifier formats supported by 
842 this authority. See Section 8.3 of [SAMLCore] for some possible values for this element. 


843 The following schema fragment defines the <AuthnAuthorityDescriptor> element and its 
844  AuthnAuthorityDescriptorType complex type: 


845 Xelement name-"AuthnAuthorityDescriptor" 

846 type-"md:AuthnAuthorityDescriptorType"/» 

847 <complexType name="AuthnAuthorityDescriptorType"> 

848 <complexContent> 

849 <extension base="md:RoleDescriptorType"> 

850 <sequence> 

851 <element ref="md:AuthnQueryService" maxOccurs="unbounded"/> 
852 <element ref="md:AssertionIDRequestService" minOccurs="0" 
853 maxOccurs="unbounded"/> 

854 <element ref-"md:NamelDFormat" minOccurs="0" 

855 maxOccurs="unbounded"/> 

856 </sequence> 

857 </extension> 

858 </complexContent> 

859 </complexType> 

860 <element name="AuthnQueryService" type="md:EndpointType"/> 


sei 2.4.6 Element <PDPDescriptor> 


862 The <PDPDescriptor> element extends RoleDescriptorType with content reflecting profiles specific to 
863 policy decision points, SAML authorities that respond to <samlp:AuthzDecisionQuery> messages. Its 
864  PDPDescriptorType complex type contains the following additional element: 
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<AuthzService> [One or More] 


One or more elements of type EndpointType that describe endpoints that support the profile of 
the Authorization Decision Query protocol defined in [SAMLProf]. All policy decision points support 
at least one such endpoint, by definition. 


«AssertionIDRequestService» [Zero or More] 


Zero or more elements of type EndpointType that describe endpoints that support the profile of 
the Assertion Request protocol defined in [SAMLProf] or the special URI binding for assertion 
requests defined in [SAMLBind]. 


«NameIDFormat» [Zero or More] 
Zero or more elements of type anyURI that enumerate the name identifier formats supported by 
this authority. See Section 8.3 of [SAMLCore] for some possible values for this element. 


The following schema fragment defines the «PDPDescriptor» element and its PDPDescriptorType 
complex type: 


<element name="PDPDescriptor" type-"md:PDPDescriptorType"/» 
<complexType name="PDPDescriptorType"> 
<complexContent> 
<extension base="md:RoleDescriptorType"> 
<sequence> 
<element ref-"md:AuthzService" maxOccurs="unbounded"/> 
<element ref="md:AssertionIDRequestService" minOccurs="0" 
maxOccurs="unbounded"/> 
<element ref-"md:NameIDFormat" minOccurs="0" 
maxOccurs="unbounded"/> 
</sequence> 
</extension> 
</complexContent> 
</complexType> 
<element name="AuthzService" type="md:EndpointType"/> 


2.4.7 Element <AttributeAuthorityDescriptor> 


The <AttributeAuthorityDescriptor> element extends RoleDescriptorType with content 
reflecting profiles specific to attribute authorities, SAML authorities that respond to 
<samlp:AttributeQuery> messages. Its AttributeAuthorityDescriptorType complex type contains 
the following additional elements: 


<AttributeService> [One or More] 


One or more elements of type EndpointType that describe endpoints that support the profile of 
the Attribute Query protocol defined in [SAMLProf]. All attribute authorities support at least one 
such endpoint, by definition. 


«AssertionIDRequestService» [Zero or More] 


Zero or more elements of type EndpointType that describe endpoints that support the profile of 
the Assertion Request protocol defined in [SAMLProf] or the special URI binding for assertion 
requests defined in [SAMLBind]. 
<NameIDFormat> [Zero or More] 
Zero or more elements of type anyURI that enumerate the name identifier formats supported by 
this authority. See Section 8.3 of [SAMLCore] for some possible values for this element. 
<AttributeProfile> [Zero or More] 


Zero or more elements of type anyURI that enumerate the attribute profiles supported by this 
authority. See [SAMLProf] for some possible values for this element. 
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912 <saml:Attribute> [Zero or More] 


913 Zero or more elements that identify the SAML attributes supported by the authority. Specific 
914 values MAY optionally be included, indicating that only certain values permitted by the attribute's 
915 definition are supported. 


916 The following schema fragment defines the <AttributeAuthorityDescriptor> element and its 
917  AttributeAuthorityDescriptorType complex type: 


918 <element name="AttributeAuthorityDescriptor" 

919 type="md:AttributeAuthorityDescriptorType"/> 

920 <complexType name="AttributeAuthorityDescriptorType"> 

921 <complexContent> 

922 <extension base="md:RoleDescriptorType"> 

923 <sequence> 

924 <element ref="md:AttributeService" maxOccurs="unbounded"/> 
925 <element ref="md:AssertionIDRequestService" minOccurs="0" 
926 maxOccurs-"unbounded"/» 

927 <element ref-"md:NameIDFormat" minOccurs="0" 

928 maxOccurs-"unbounded"/» 

929 <element ref="md:AttributeProfile" minOccurs="0" 

930 maxOccurs-"unbounded"/» 

931 <element ref-"saml:Attribute" minOccurs="0" 

932 maxOccurs-"unbounded"/» 

933 </sequence> 

934 </extension> 

935 </complexContent> 

936 </complexType> 

937 <element name-"AttributeService" type="md:EndpointType"/> 


98 2.5 Element <AffiliationDescriptor> 


939 The <AffiliationDescriptor> element is an alternative to the sequence of role descriptors 

940 described in Section 2.4 that is used when an <EntityDescriptor> describes an affiliation of SAML 
941 entities (typically service providers) rather than a single entity. The <AffiliationDescriptor> 

942 element provides a summary of the individual entities that make up the affiliation along with general 

943 information about the affiliation itself. Its AffiliationDescriptorType complex type contains the following 
944 elements and attributes: 


945  affiliationOwnerID [Required] 


946 Specifies the unique identifier of the entity responsible for the affiliation. The owner is NOT 
947 presumed to be a member of the affiliation; if it is a member, its identifier MUST also appear in an 
948 <AffiliateMember> element. 


949 ID [Optional] 
950 A document-unique identifier for the element, typically used as a reference point when signing. 


951  validUntil [Optional] 

952 Optional attribute indicates the expiration time of the metadata contained in the element and any 
953 contained elements. 

954  cacheDuration [Optional] 

955 Optional attribute indicates the maximum length of time a consumer should cache the metadata 
956 contained in the element and any contained elements. 


957  «ds:Signature» [Optional] 


958 An XML signature that authenticates the containing element and its contents, as described in 
959 Section 3. 
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960 «Extensions» [Optional] 


961 This contains optional metadata extensions that are agreed upon between a metadata publisher 
962 and consumer. Extension elements MUST be namespace-qualified by a non-SAML defined 
963 namespace. 


964 <AffiliateMember> [One or More] 


965 One or more elements enumerating the members of the affiliation by specifying each member's 
966 unique identifier. See also Section 8.3.6 of [SAML Core]. 

967  «KeyDescriptor» [Zero or More] 

968 Optional sequence of elements that provides information about the cryptographic keys that the 
969 affiliation uses as a whole, as distinct from keys used by individual members of the affiliation, 
970 which are published in the metadata for those entities. 


971 Arbitrary namespace-qualified attributes from non-SAML-defined namespaces may also be included. 


972 The following schema fragment defines the <AffiliationDescriptor> element and its 
973  AffiliationDescriptorType complex type: 


974 <element name-"AffiliationDescriptor" type-"md:AffiliationDescriptorType"/» 
975 <complexType name="AffiliationDescriptorType"> 

976 <sequence> 

977 <element ref="ds:Signature" minOccurs="0"/> 

978 <element ref="md:Extensions" minOccurs="0"/> 

979 <element ref="md:AffiliateMember" maxOccurs="unbounded"/> 

980 <element ref-"md:KeyDescriptor" minOccurs="0" maxOccurs="unbounded"/> 
981 </sequence> 

982 «attribute name-"affiliationOwnerID" type-"md:entityIDType" 

983 use-"required"/» 

984 «attribute name="validUntil" type-"dateTime" use-"optional"/» 

985 «attribute name-"cacheDuration" type-"duration" use-"optional"/» 

986 «attribute name-"ID" type-"ID" use-"optional"/» 

987 «anyAttribute namespace="##other" processContents-"lax"/» 

988 «/complexType» 

989 «element name-"AffiliateMember" type-"md:entityIDType"/» 


90 2.6 Examples 


991 The following is an example of metadata for a SAML system entity acting as an identity provider and an 


992 attribute authority. A signature is shown as a placeholder, without the actual content. 
993 


994 <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" 

995 xmlns:saml-"urn:oasis:names:tc:SAML:2.0:assertion" 

996 xmlns:ds="http://www.w3.0rg/2000/09/xmldsigt" 

997 entityID-"https://IdentityProvider.com/SAML"» 

998 <ds:Signature>...</ds:Signature> 

999 <IDPSSODescriptor WantAuthnRequestsSigned="true" 

1000 protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> 

1001 <KeyDescriptor use="signing"> 

1002 «ds:KeyInfo- 

1003 <ds:KeyName>IdentityProvider.com SSO Key</ds:KeyName> 

1004 </ds:KeyInfo> 

1005 </KeyDescriptor> 

1006 <ArtifactResolutionService isDefault-"true" index="0" 

1007 Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" 

1008 Location="https://IdentityProvider.com/SAML/Artifact"/> 

1009 <SingleLogoutService 

1010 Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" 

1011 Location="https://IdentityProvider.com/SAML/SLO/SOAP"/> 

1012 <SingleLogoutService 

1013 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" 

1014 Location="https://IdentityProvider.com/SAML/SLO/Browser" 

1015 ResponseLocation-"https://IdentityProvider.com/SAML/SLO/Response"/» 
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1016 
1017 
1018 
1019 
1020 
1021 
1022 
1023 
1024 
1025 
1026 
1027 
1028 
1029 
1030 
1031 
1032 
1033 
1034 
1035 
1036 
1037 
1038 
1039 
1040 
1041 
1042 
1043 
1044 
1045 
1046 
1047 
1048 
1049 
1050 
1051 
1052 
1053 
1054 
1055 
1056 
1057 
1058 
1059 
1060 
1061 
1062 
1063 
1064 
1065 
1066 
1067 
1068 
1069 
1070 
1071 
1072 
1073 
1074 
1075 
1076 
1077 
1078 
1079 
1080 
1081 
1082 


<NameIDFormat> 
urn:oasis:names:tc: SAMI 
</NameIDFormat> 
<NameIDFormat> 
urn:oasis:names:tc: SAMI 
</NameIDFormat> 
<NameIDFormat> 
urn:oasis:names:tc: SAMI 
</NameIDFormat> 
<SingleSignOnService 


<SingleSignOnService 


<saml:Attribute 


</saml:Attribute> 
<saml:Attribute 


L:1.1:nameid- 


L:2.0:nameid- 


L:2.0:nameid- 


format:X509SubjectName 


format:persistent 


format:transient 


Binding-"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" 
Location="https://IdentityProvider.com/SAML/SSO/Browser"/> 


Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
Location="https://IdentityProvider.com/SAML/SSO/Browser"/> 


NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
Names turni oboe. S56 jd Å, 15928 i. il sil od 
FriendlyName="eduPersonPrincipalName"> 


NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
Nannies eins oakel Sil. 356d AA, 159251 sal a! 


FriendlyName="eduPersonAffiliation"> 


<saml: 
<saml: 


<saml: 


ttributeValue>employ 


<saml: 
</saml:Attribute> 


</IDPSSODescriptor> 
<AttributeAuthorityDescriptor 
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> 


<KeyDescriptor use="signing"> 


«ds:KeyInfo» 


AttributeValue>member</saml:AttributeValue> 
AttributeValue>student</saml:AttributeValue> 
<saml:AttributeValue>faculty</saml:AttributeValue> 
A </saml:AttributeValue> 
AttributeValue>staff</saml:AttributeValue> 


<ds:KeyName>IdentityProvider.com AA Key</ds:KeyName> 


</ds:KeyInfo> 
</KeyDescriptor> 
<AttributeService 


<AssertionIDRequestService 


<Name IDFormat> 
urn:oasis:names:tc: SAMI 
</NameIDFormat> 
<Name IDFormat> 
urn:oasis:names:tc: SAMI 
</NameIDFormat> 
<NameIDFormat> 
urn:oasis:names:tc:SAMI 
</NameIDFormat> 
<saml:Attribute 


L:1.1:nameid- 


L:2.0:nameid- 


L:2.0:nameid- 


NameFormat-"urn:oasis:names:tc:SAML: 
Nannies turno Kan One s 4.5 1L 5592 SI TE il sal od) 


Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" 
Location="https://IdentityProvider.com/SAML/AA/SOAP"/> 


Binding="urn:oasis:names:tc:SAML:2.0:bindings:URI" 
Location="https://IdentityProvider.com/SAML/AA/URI"/> 


format :X509SubjectName 


format:persistent 


format:transient 


2.0:attrname-format:uri" 


FriendlyName="eduPersonPrincipalName"> 


«/saml:Attribute» 
<saml:Attribute 


NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
Nannies rent sacl 1. 5 356d 4L, 1L 3592 i. sal al! 
FriendlyName="eduPersonAffiliation"> 


<saml: 
<saml: 


<saml: 
<saml: 
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ttributeValue»employ 
ttributeValue»staff«/saml:AttributeValue» 


AttributeValue>member</saml:AttributeValue> 
AttributeValue>student</saml:AttributeValue> 
<saml:AttributeValue>faculty</saml:AttributeValue> 
A «/saml:AttributeValue» 
A 
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1083 </saml:Attribute> 

1084 </AttributeAuthorityDescriptor> 

1085 <Organization> 

1086 <OrganizationName xml:lang="en">Identity Providers R 
1087 US</OrganizationName> 

1088 <OrganizationDisplayName xml:lang="en"> 

1089 Identity Providers R US, a Division of Lerxst Corp. 
1090 </OrganizationDisplayName> 

1091 <OrganizationURL 

1092 xml:lang="en">https://IdentityProvider.com</OrganizationURL> 
1093 </Organization> 

1094 </EntityDescriptor> 

1095 


1096 The following is an example of metadata for a SAML system entity acting as a service provider. A 

1097 signature is shown as a placeholder, without the actual content. For illustrative purposes, the service is 
1098 one that does not require users to uniquely identify themselves, but rather authorizes access on the basis 
1099 of a role-like attribute. 


1100 

1101 <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" 

1102 xmlns:saml-"urn:oasis:names:tc:SAML:2.0:assertion" 

1103 xmlns:ds="http://www.w3.0rg/2000/09/xmldsigt" 

1104 entityID="https://ServiceProvider.com/SAML"> 

1105 <ds:Signature>...</ds:Signature> 

1106 <SPSSODescriptor AuthnRequestsSigned="true" 

1107 protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> 
1108 <KeyDescriptor use="signing"> 

1109 «ds:KeyInfo» 

1110 <ds:KeyName>ServiceProvider.com SSO Key</ds:KeyName> 

1111 </ds:KeyInfo> 

1112 </KeyDescriptor> 

1113 <KeyDescriptor use="encryption"> 

1114 «ds:KeyInfo» 

1115 <ds:KeyName>ServiceProvider.com Encrypt Key</ds:KeyName> 
1116 «/ds:KeyInfo» 

1117 <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa- 
1118 d 59/> 

1119 </KeyDescriptor> 

1120 <SingleLogoutService 

1121 Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" 

1122 Location="https://ServiceProvider.com/SAML/SLO/SOAP"/> 

1123 <SingleLogoutService 

1124 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" 
1125 Location="https://ServiceProvider.com/SAML/SLO/Browser" 

1126 ResponseLocation="https://ServiceProvider.com/SAML/SLO/Response"/> 
1127 «NameIDFormat» 

1128 urn:o0asis:names:tc:SAML:2.0:nameid-format:transient 

1129 </NameIDFormat> 

1130 <AssertionConsumerService isDefault="true" index="0" 

1131 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" 
1132 Location="https://ServiceProvider.com/SAML/SSO/Artifact"/> 

1133 <AssertionConsumerService index="1" 

1134 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 

1135 Location="https://ServiceProvider.com/SAML/SSO/POST"/> 

1136 <AttributeConsumingService index="0"> 

1137 <ServiceName xml:lang="en">Academic Journals R US</ServiceName> 
1138 <RequestedAttribute 

1139 NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
1140 Name Aaro a dL si o19« 1l ots T0190: 5 iis TE STM 

1141 FriendlyName="eduPersonEntitlement"> 

1142 <saml:AttributeValue> 

1143 https://ServiceProvider.com/entitlements/123456789 

1144 </saml:AttributeValue> 

1145 </RequestedAttribute> 

1146 </AttributeConsumingService> 

1147 </SPSSODescriptor> 

1148 <Organization> 
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1149 
1150 
1151 
1152 
1153 
1154 
1155 
1156 
1157 


<OrganizationName xml:lang="en">Academic Journals R 
US</OrganizationName> 
<OrganizationDisplayName xml:lang="en"> 
Academic Journals R US, a Division of Dirk Corp. 
</OrganizationDisplayName> 
<OrganizationURL 
xml:lang="en">https://ServiceProvider.com</OrganizationURL> 
</Organization> 
</EntityDescriptor> 
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1158 


1159 
1160 


1161 


1162 


1163 
1164 
1165 


1166 
1167 
1168 


1169 


1170 
1171 


1172 


1173 
1174 
1175 
1176 
1177 


1178 


1179 
1180 


1181 
1182 
1183 


1184 


1185 
1186 
1187 


1188 
1189 
1190 


1191 


1192 


1193 


1194 
1195 
1196 


3 Signature Processing 


Various elements in a metadata instance can be digitally signed (as indicated by the element's inclusion of 
a <ds:Signature> element), with the following benefits: 


* Metadata integrity 


* Authentication of the metadata by a trusted signer 


A digital signature is not always required, for example if the relying party obtains the information directly 
from the publishing entity directly (with no intermediaries) through a secure channel, with the entity having 
authenticated to the relying party by some means other than a digital signature. 


Many different techniques are available for "direct" authentication and secure channel establishment 
between two parties. The list includes TLS/SSL, HMAC, password-based mechanisms, etc. In addition, 
the applicable security requirements depend on the communicating applications. 


Additionally, elements can inherit signatures on enclosing parent elements that are themselves signed. 


In the absence of such context, itis RECOMMENDED that at least the root element of a metadata 
instance be signed. 


3.1 XML Signature Profile 


The XML Signature specification [XMLSig] calls out a general XML syntax for signing data with flexibility 
and many choices. This section details the constraints on these facilities so that metadata processors do 
not have to deal with the full generality of XML Signature processing. This usage makes specific use of 
the xs:ID-typed attributes optionally present on the elements to which signatures can apply. These 
attributes are collectively referred to in this section as the identifier attributes. 


3.1.1 Signing Formats and Algorithms 


XML Signature has three ways of relating a signature to a document: enveloping, enveloped, and 
detached. 


SAML metadata MUST use enveloped signatures when signing the elements defined in this specification. 
SAML processors SHOULD support the use of RSA signing and verification for public key operations in 
accordance with the algorithm identified by http:/www.w3.org/2000/09/xmldsig#rsa-sha1. 


3.1.2 References 


Signed metadata elements MUST supply a value for the identifier attribute on the signed element. The 
element may or may not be the root element of the actual XML document containing the signed metadata 
element. 


Signatures MUST contain a single «ds : Reference» containing a URI reference to the identifier attribute 
value of the metadata element being signed. For example, if the identifier attribute value is "foo", then the 
URI attribute in the <ds:Reference> element MUST be "#foo". 


As a consequence, a metadata element's signature MUST apply to the content of the signed element and 
any child elements it contains. 


3.1.3 Canonicalization Method 


SAML implementations SHOULD use Exclusive Canonicalization, with or without comments, both in the 
«ds:CanonicalizationMethod» element of <ds:SignedInfo>, and as a <ds:Transform> 
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1197 embedded in an XML context can be verified independent of that context. 


1198 3.1.4 Transforms 


1199 Signatures in SAML metadata SHOULD NOT contain transforms other than the enveloped signature 
1200 transform (with the identifier http://www.w3.org/2000/09/xmldsig£enveloped-signature) or the exclusive 
1201  canonicalization transforms (with the identifier http://www.w3.org/2001/10/xml-exc-c14n# or 

1202  http://www.w3.org/2001/10/xml-exc-c14nZWithComments). 


1203  Verifiers of signatures MAY reject signatures that contain other transform algorithms as invalid. If they do 
1200 not, verifiers MUST ensure that no content of the signed metadata element is excluded from the 

1205 signature. This can be accomplished by establishing out-of-band agreement as to what transforms are 
1206 acceptable, or by applying the transforms manually to the content and reverifying the result as consisting 
1207 ofthe same SAML metadata. 


1208 3.1.5 Keylnfo 


1209 XML Signature [XMLSig] defines usage of the <ds:KeyInfo> element. SAML does not require the 
1210 use of <ds:KeyInfo> nor does it impose any restrictions on its use. Therefore, «ds:KeyInfo» MAY 
1211 be absent. 
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1212 


1213 
1214 
1215 
1216 
1217 
1218 


1219 
1220 
1221 


1222 
1223 
1224 
1225 


1226 


1227 


1228 


1229 
1230 
1231 
1232 
1233 
1234 
1235 


1236 
1237 
1238 
1239 
1240 
1241 


1242 


1243 
1244 


1245 


1246 
1247 
1248 
1249 
1250 


4 Metadata Publication and Resolution 


Two mechanisms are provided for an entity to publish (and for a consumer to resolve the location of) 
metadata documents: via a "well-known-location" by directly dereferencing the entity's unique identifier (a 
URI variously referred to as an entitylD or providerID), or indirectly by publishing the location of metadata 
in the DNS. Other out-of-band mechanisms are of course also permitted. A consumer that supports both 
approaches defined in this document MUST attempt resolution via DNS before using the "well-known- 
location" mechanism. 


When retrieval requires network transport of the document, the transport SHOULD be protected with 
mechanisms providing server authentication and integrity protection. For example, HTTP-based resolution 
SHOULD be protected with TLS/SSL [RFC 2246] as amended by [RFC3546]. 


Various mechanisms are described in this section to aid in establishing trust in the accuracy and 
legitimacy of metadata, including use of XML signatures, SSL/TLS server authentication, and DNS 
signatures. Regardless of the mechanism(s) used, relying parties SHOULD have some means by which to 
establish trust in metadata information before relying on it. 


4.1 Publication and Resolution via Well-Known Location 


The following sections describe publication and resolution of metadata by means of a well-known location. 


4.1.1 Publication 


Entities MAY publish their metadata documents at a well known location by placing the document at the 
location denoted by its unique identifier, which MUST be in the form of a URL (rather than a URN). See 
Section 8.3.6 of [SAML Core] for more information about such identifiers. It is STRONGLY 
RECOMMENDED that https URLs be used for this purpose. An indirection mechanism supported by the 
URL scheme (such as an HTTP 1.1 302 redirect) MAY be used if the document is not placed directly at 
the location. If the publishing protocol permits MIME-based identification of content types, the content type 
of the metadata instance MUST be application/samlmetadata+xml. 


The XML document provided at the well-known location MUST describe the metadata only for the entity 
represented by the unique identifier (that is, the root element MUST be an «EntityDescriptor» with 
an entityID matching the location). If other entities need to be described, the 
<AdditionalMetadataLocation> element MUST be used. Thus the <EntitiesDescriptor> 
element MUST NOT be used in documents published using this mechanism, since a group of entities are 
not defined by such an identifier. 


4.1.2 Resolution 


If an entity's unique identifier is à URL, metadata consumers MAY attempt to resolve an entity's unique 
identifier directly, in a scheme-specific manner, by dereferencing the identifier. 


4.2 Publishing and Resolution via DNS 


To improve the accessibility of metadata documents and provide additional indirection between an entity's 
unique identifier and the location of metadata, entities MAY publish their metadata document locations in a 
zone of their corresponding DNS [RFC 1034]. The entity's unique identifier (a URI) is used as the input to 
the process. Since URIs are flexible identifiers, location publication methods and the resolution process 
are determined by the URI's scheme and fully-qualified name. URI locations for metadata are 
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subsequently be derived through queries of the NAPTR Resource Record (RR) as defined in [RFC2915] 
and [RFC3403]. 


It is RECOMMENDED that entities publish their resource records in signed zone files using [RFC2535] 
such that relying parties may establish the validity of the published location and authority of the zone, and 
integrity of the DNS response. If DNS zone signatures are present, relying parties MUST properly validate 
the signature. 


4.2.1 Publication 


This specification makes use of the NAPTR resource record described in [RFC2915] and [RFC3403]. 
Familiarity with these documents is encouraged. 


Dynamic Delegation Discovery System (DDDS) [RFC3401]is a general purpose system for the retrieval of 
information based on an application-specific input string and the application of well known rules to 
transform that string until a terminal condition is reached requiring a look-up into an application-specific 
defined database or resolution of a URL based on the rules defined by the application. DDDS defines a 
specific type of DNS Resource Record, NAPTR records, for the storage of information in the DNS 
necessary to apply DDDS rules. 


Entities MAY publish separate URLs when multiple metadata documents need to be distributed, or when 
different metadata documents are required due to multiple trust relationships that require separate keying 
material, or when service interfaces require separate metadata declarations. This may be accomplished 
through the use of the optional <AdditionalMetadataLocation> element, or through the regexp 
facility and multiple service definition fields in the NAPTR resource record itself. 


If the publishing protocol permits MIME-based identification of content types, the content type of the 
metadata instance MUST be application/samlmetadata+xml. 


If the entity's unique identifier is a URN, publication of the corresponding metadata location proceeds as 
specified in [RFC3404]. Otherwise, the resolution of the metadata location proceeds as specified below. 


The following is the application-specific profile of DDDS for SAML metadata resolution. 


4.2.1.1 First Well Known Rule 


The "first well-known-rule" for processing SAML metadata resolution is to parse the entity's unique 
identifier and extract the fully-qualified domain name (subexpression 3) as described in Section 4.2.3.1. 


4.2.1.2 The Order Field 


The order field indicates the order for processing each NAPTR resource record returned. Publishers MAY 
provide multiple NAPTR resource records which MUST be processed by the resolver application in the 
order indicated by this field. 


4.2.1.3 The Preference Field 


For terminal NAPTR resource records, the publisher expresses the preferred order of use to the resolving 
application. The resolving application MAY ignore this order, in cases where the service field value does 
not meet the resolver's requirements (e.g.: the resource record returns a protocol the application does not 
support). 


saml-metadata-2.0-os 15 March 2005 
Copyright € OASIS Open 2005 All Rights Reserved. Page 30 of 43 


1288 


1289 
1290 
1291 


1292 


1293 
1294 
1295 
1296 
1297 
1298 
1299 
1300 
1301 


1302 
1303 


1304 


1305 
1306 


1307 
1308 
1309 
1310 


1311 
1312 
1313 
1314 
1315 


1316 
1317 


1318 


1319 
1320 


1321 
1322 


1323 
1324 


1325 


1326 


1327 
1328 


4.2.1.4 The Flag Field 


SAML metadata resolution twice makes use of the "U" flag, which is terminal, and the null value (implying 
additional resource records are to be processed). The "U" flag indicates that the output of the rule is a 
URI. 


4.2.1.5 The Service Field 


The SAML-specific service field, as described in the following BNF, declares the modes by which instance 
document(s) shall be made available: 


ETS heel = dL(ugaEDEU / “Nap Wa? peso [oe (Val class) (Us sesitcernos) | 

poro = JL Urteel / Umerit) 

class = 1[ "entity" / "entitygroup" ) 

servicetype = 1(si / "spsso" / "idpsso" / "authn" / "authnauth" / "pdp" / "attrauth" / 
alphanum ) 

si = Vgi! [sw eullolnemunn)) ["aendsorne" | 

alphanum = 1*32(ALPHA / DIGIT) 


where: 
* servicefield PID2U resolves an entity's unique identifier to metadata URL. 


e servicefield NID2U resolves a principal's <NameID> into a metadata URL. 


* proto describes the retrieval protocol (https or uddi). In the case of UDDI, the URL will be an 
http(s) URL referencing a WSDL document. 


* class identifies whether the referenced metadata document describes a single entity, or multiple. 
In the latter case, the referenced document MUST contain the entity defined by the original unique 
identifier as a member of a group of entities within the document itself such as an 
<AffiliationDescriptor> or«EntitiesDescriptor». 


* servicetype allows an entity to publish metadata for distinct roles and services as separate 
documents. Resolvers who encounter multiple servicetype declarations will dereference the 
appropriate URI, depending on which service is required for an operation (e.g.: an entity operating 
both as an identity provider and a service provider can publish metadata for each role at different 
locations). The authn service type represents a <SingleSignOnService> endpoint. 


* si (with optional endpoint component) allows the publisher to either directly publish the metadata 
for a service instance, or by articulating a SOAP endpoint (using endpoint). 
For example: 


* PID2U+https:entity -represents the entity's complete metadata document available via the 
https protocol 


* PID2U+uddi:entity:si:foo -represents the WSDL document location that describes a service 
instance "foo" 


* PID2U+https:entitygroup: idpsso -represents the metadata for a group of entities acting as 
SSO identity providers, of which the original entity is a member. 


* NID2U+https:idp -represents the metadata for the SSO identity provider of a principal 


4.2.1.6 The Regex and Replacement Fields 


The expected output after processing the input string through the regex MUST be a valid https URL or 
UDDI node (WSDL document) address. 
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4.2.2 NAPTR Examples 


4.2.2.1 Entity Metadata NAPTR Examples 


Entities publish metadata URLs in the following manner: 
SORIGIN provider.biz 


7; order pref f service regexp or replacement 


IN NAPTR 100 10 "U" PID2U+https:entity 
UIA c es S litros: A MOISE o provider. kis / Some/Chiaacirory/iceusic sal V, Ww 
JON NEAD LO 10 "ADM IP IDAHO OSS (GlnEJIESZE EIZUISIE 
VIA c gs levers 8 A // OO o provider olo. o 1419 fmohewusic semi pU Vn 
JON NARIZ 125 10 4! (SUD bere GH 
IN NAPTR 110 10 "U" PID2U+uddi:entity 
VIA SS lnaross/ / this Ueci nodes provider Jet e eme, seld" WY 


4.2.2.2 Name Identifier Examples 


A principal's employer example.int operates an identity provider which may be used by an office supply 
company to authenticate authorized buyers. The supplier takes a users' email address 
buyer@example.int as input to the resolution process, and parses the email address to extract the 
FQDN (example.int). The employer publishes the following NAPTR record in the example. int DNS: 


SORIGIN example.int 


IN NAPTR 100 10 "U" NID2U+https:authn 

BIS PETE) S lLlang eo 8 // / Sexe wv o sera die a inte SOOO /ecaignin/eercimnel? VIN Wn 
IN NAPTR 100 10 "U" NID2U+https:idp 

BLS C Eo pp fe (59) S Tine teresa / /auitin example, ime/epp/amilae\Ly PU 


4.2.3 Resolution 
When resolving metadata for an entity via the DNS, the unique identifier of the entity is used as the initial 
input into the resolution process, rather than as an actual location Proceed as follows: 

* Ifthe unique identifier is a URN, proceed with the resolution steps as defined in [RFC3404]. 

* Otherwise, parse the identifier to obtain the fully-qualified domain name. 


* Query the DNS for NAPTR resource records of the domain iteratively until a terminal resource 
record is returned. 


* Identify which resource record to use based on the service fields, then order fields, then preference 
fields of the result set. 


* Obtain the document(s) at the provided location(s) as required by the application. 


4.2.3.1 Parsing the Unique Identifier 


To initiate the resolution of the location of the metadata information, it will be necessary in some cases to 
decompose the entity's unique identifier (expressed as a URI) into one or more atomic elements. 


The following regular expression should be used when initiating the decomposition process: 


^([^8/25]38) 2/9 US ARON 2 (CIS Feet ND EENEG (^7 858 No 1188) 23 
(8 wel 9 (L^ 9: 8). QVE IL^3] E909 8 (ra) 9$ 
1 2 34 56 7 8 
9 10 id 


Subexpression 3 MUST result in a Fully-Qualified Domain Name (FQDN), which will be the basis for 
retrieving metadata locations from this zone. 
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4.2.3.2 Obtaining Metadata via the DNS 


Upon completion of the parsing of the identifier, the application then performs a DNS query for the resulting 
domain (subexpression 5) for NAPTR resource records; it should expect 1 or more responses. 
Applications MAY exclude from the result set any service definitions that do not concern the present 
request operations. 


Resolving applications MUST subsequently order the result set according to the order field, and MAY 
order the result set based on the preference set. Resolvers are NOT REQUIRED to follow the ordering of 
the preferences field. The resulting NAPTR resource record(s) are operated on iteratively (based on the 
order flag) until a terminal NAPTR resource record is reached. 


The result will be a well-formed, absolute URL, which is then used to retrieve the metadata document. 


4.2.4 Metadata Location Caching 


Location caching MUST NOT exceed the TTL of the DNS zone from which the location was derived. 
Resolvers MUST obtain a fresh copy of the metadata location upon reaching the expiration of the TTL of 
the zone. 


Publishers of metadata documents should carefully consider the TTL of the zone when making changes 
to metadata document locations. Should such a location change occur, a publisher MUST either keep the 
document at both the old and new location until all conforming resolvers are certain to have the updated 
location (e.g.: time of zone change + TTL), or provide an HTTP Redirect [RFC2616] response at the old 
location specifying the new location. 


4.3 Post-Processing of Metadata 


The following sections describe the post-processing of metadata. 


4.3.1 Metadata Instance Caching 


Document caching MUST NOT exceed the validUntil or cacheDuration attribute of the subject 
element(s). If metadata elements have parent elements which contain caching policies, the parent 
element takes precedence. 


To properly process the cacheDuration attribute, consumers MUST retain the date and time when the 
document was retrieved. 


When a document or element has expired, the consumer MUST retrieve a fresh copy, which may require 
a refresh of the document location(s). Consumers SHOULD process document cache processing 
according to [RFC2616] Section 13, and MAY request the Last-Modified date and time from the HTTP 
server. Publishers SHOULD ensure acceptable cache processing as described in [RFC2616] (Section 
10.3.5 304 Not Modified). 


4.3.2 Handling of HTTPS Redirects 


Publishers MAY issue an HTTP Redirect (301 Moved Permanently, 302 or 307 Temporary Redirect) 
[RFC2616], and user agents MUST follow the specified URL in the Redirect response. Redirects 
SHOULD be of the same protocol as the initial request. 


4.3.3 Processing of XML Signatures and General Trust Processing 


Metadata processing provides several mechanisms for trust negotiation for both the metadata itself and 
for the trust ascribed to the entity described by such metadata: 


* Trust derived from the signature of the DNS zone from which the metadata location URL was 
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resolved, ensuring accuracy of the metadata document location(s) 


* Trust derived from signature processing of the metadata document itself, ensuring the integrity of 
the XML document 


* Trust derived from the SSL/TLS server authentication of the metadata location URL, ensuring the 
identity of the publisher of the metadata 


Post-processing of the metadata document MUST include signature processing at the XML-document 
level and MAY include one of the other two processes. Specifically, the relying party MAY choose to trust 
any of the cited authorities in the resolution and parsing process. Publishers of metadata MUST employ a 
document-integrity mechanism and MAY employ any of the other two processing profiles to establish trust 
in the metadata document, governed by implementation policies. 


4.3.3.1 Processing Signed DNS Zones 


Verification of DNS zone signature SHOULD be processed, if present, as described in [RFC2535]. 


4.3.3.2 Processing Signed Documents and Fragments 


Published metadata documents SHOULD be signed, as described in Section 3, either by a certificate 
issued to the subject of the document, or by another trusted party. Publishers MAY consider signatures of 
other parties as a means of trust conveyance. 


Metadata consumers MUST validate signatures, when present, on the metadata document as described 
by Section 3. 


4.3.3.3 Processing Server Authentication during Metadata Retrieval via TLS/SSL 


Itis STRONGLY RECOMMENDED that publishers implement TLS/SSL URLs; therefore, consumers 
SHOULD consider the trust inherited from the issuer of the TLS/SSL certificate. Publication URLs may not 
always be located in the domain of the subject of the metadata document; therefore, consumers SHOULD 
NOT presume certificates whose subject is the entity in question, as it may be hosted by another trusted 


party. 


As the basis of this trust may not be available against a cached document, other mechanisms SHOULD 
be used under such circumstances. 
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Appendix A.Registration of MIME media type 
application/samlImetadata*xml 


Introduction 


This document defines a MIME media type -- application/samlmetadata+xml --for use 
with the XML serialization of Security Assertion Markup Language metadata. 


SAML is a work product of the OASIS Security Services Technical Committee [SSTC]. The SAML 
specifications define XML-based constructs with which one may make, and convey, security 
assertions. Using SAML, one can assert that an authentication event pertaining to some subject 
has occurred and convey said assertion to a relying party, for example. 


SAML profiles require agreements between system entities regarding identifiers, binding support, 
endpoints, certificates, keys, and so forth. Such information is treated as metadata by SAML v2.0. 
[SAMLv2Meta] specifies this metadata, as well as specifying metadata publication and resolution 
mechanisms. If the publishing protocol permits MIME-based identification of content types, then 
use of the application/samlmetadata+xml MIME media type is required. 


MIME media type name 


application 


MIME subtype name 


samlmetadatatxml 


Required parameters 


None 


Optional parameters 


charset 
Same as charset parameter of application/xml [RFC3023]. 


Encoding considerations 
Same as for application/xml [RFC3023]. 


Security considerations 


Per their specification, sam1metadata-xml typed objects do not contain executable content. 
However, these objects are XML-based [XML], and thus they have all of the general security 
considerations presented in Section10 of [RFC3023]. 


SAML metadata [SAMLv2Meta] contains information whose integrity and authenticity is important 
— identity provider and service provider public keys and endpoint addresses, for example. 


To counter potential issues, the publisher may sign samlmetadata+xml typed objects. Any such 
signature should be verified by the recipient of the data - both as a valid signature, and as being 
the signature of the publisher. 


Additionally, various of the publication protocols, e.g. HTTP-over-TLS/SSL, offer means for 
ensuring the authenticity of the publishing party and for protecting the metadata in transit. 
[SAMLv2Meta] also defines prescriptive metadata caching directives, as well as guidance on 
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handling HTTPS redirects, trust processing, server authentication, and related items. 


For a more detailed discussion of SAML v2.0 metadata and its security considerations, please 
see [SAMLv2Meta]. For a discussion of overall SAML v2.0 security considerations and specific 
security-related design features, please refer to the SAML v2.0 specifications listed in the below 
bibliography. The specifications containing security-specific information are explicitly listed. 


Interoperability considerations 


SAML v2.0 metadata explicitly supports identifying the protocols and versions supported by the 
identified entities. For example, an identity provider entity can be denoted as supporting SAML 
v2.0 [SAMLv2.0], SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2 [LAPFF], or even other protocols if 
they are unambiguously identifiable via URI [RFC2396]. This protocol support information is 
conveyed via the protocolSupportEnumeration attribute of metadata objects of the 
RoleDescriptorType. 


Published specification 
[SAMLv2Meta] explicitly specifies use of the application/samlmetadata+xml MIME media 
type. 

Applications which use this media type 
Potentially any application implementing SAML v2.0, as well as those applications implementing 


specifications based on SAML, e.g. those available from the Liberty Alliance [LAP]. 


Additional information 


Magic number(s) 


In general, the same as for application/xml [RFC3023]. In particular, the XML root element of 
the returned object will have a namespace-qualified name with: 


- alocal name of: EntityDescriptor, Or 
AffiliationDescriptor, Or 
EntitiesDescriptor 


— a namespace URI of: urn:oasis:names:tc:SAML:2.0:metadata 
(the SAMLv2.0 metadata namespace) 


File extension(s) 


None 


Macintosh File Type Code(s) 


None 


Person & email address to contact for further information 


This registration is made on behalf of the OASIS Security Services Technical Committee (SSTC) 
Please refer to the SSTC website for current information on committee chairperson(s) and their 
contact addresses: http://www.oasis-open.org/committees/security/. Committee members should 
submit comments and potential errata to the securityservices@lists.oasis-open.org list. Others 
should submit them by filling out the web form located at http://www.oasis- 
open.org/committees/comments/form.php?wg abbrev-security. 
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Additionally, the SAML developer community email distribution list, saml-dev(Qlists.oasis- 
open.org, may be employed to discuss usage of the application/samlmetadata+xml MIME 
media type. The "saml-dev" mailing list is publicly archived here: http://lists.oasis- 
open.org/archives/saml-dev/. To post to the "saml-dev" mailing list, one must subscribe to it. To 
subscribe, send a message with the single word "subscribe" in the message body, to: saml-dev- 
request@lists.oasis-open.org. 


Intended usage 
COMMON 


Author/Change controller 


The SAML specification sets are a work product of the OASIS Security Services Technical 
Committee (SSTC). OASIS and the SSTC have change control over the SAML specification sets. 
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